home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970326-19970626 / 000001_news@columbia.edu _Wed Mar 26 17:32:08 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA27699
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Mar 1997 17:32:07 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA12377
  7.     for kermit.misc@watsun; Wed, 26 Mar 1997 17:32:06 -0500 (EST)
  8. Path: news.columbia.edu!not-for-mail
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.os.ms-windows.nt.misc,comp.protocols.kermit.misc
  11. Subject: Re: K95 Kermit flickers on Key Input in NT4.0
  12. Date: 26 Mar 1997 17:31:58 -0500
  13. Organization: Columbia University
  14. Lines: 84
  15. Message-ID: <5hc84u$qum@watsun.cc.columbia.edu>
  16. References: <5hbo8d$lbi$1@news.impulse.net>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.os.ms-windows.nt.misc:184911 comp.protocols.kermit.misc:6816
  19.  
  20. In article <5hbo8d$lbi$1@news.impulse.net>,
  21. Stephen Au <stephen@arktel.com> wrote:
  22. : 
  23. : I have been using K95 under WIN95 for sometime and it works OK (slow)
  24. :
  25. Slow compared to what?
  26.  
  27. : and I can't use just any window size I want.
  28. :
  29. Due to a bug in Windows 95.
  30.  
  31. : I recently upgraded my system to NT 4.0...
  32. :
  33. Which does not have the bug relating to console screen dimensions...
  34.  
  35. : and the first thing I noticed was that text in K95 window flickers as I
  36. : was typing. This flickering happens even in the command screen, as well as
  37. : when connected. I have not seen this problem on WIN95, and neither does
  38. : this occur in vanilla DOS session in an NT window.  I went over to a
  39. : colleague's NT workstation and it does the same thing.
  40. : 
  41. : The system I tried are PCI-based Pentium/120 and 133 (Dell). One with the
  42. : STB PowerGraph Trio64V+ and the other one uses S3. 
  43. : 
  44. : K95 has patch 11 updates.
  45. : 
  46. Which is current.
  47.  
  48. : Does anyone has similar problem and has a remedy? Thank you very much.
  49. : 
  50. Some people have seen this, most do not see it.
  51.  
  52. : This is a big disappointment considering I have been using all versions
  53. : of Kermit in MSDOS, Unix, and OS2, and these versions are rock solid.
  54. : 
  55. In Windows, we're dealing with a much more... "complicated" environment.
  56. There are infinite combinations of hardware, graphics adapters, drivers,
  57. BIOS's, etc, and bugs in all of these.  
  58.  
  59. Kermit is updating the screen in the approved Win32 manner.  If there is
  60. flicker, it is not caused by Kermit, but rather by the driver that Kermit
  61. is calling upon to do it, and/or the video adapter.
  62.  
  63. The following entry from Kermit 95's BUGS.TXT file might be helpful:
  64.  
  65. 27. Screen updates updates are slow on some PCs
  66.  
  67. Video drivers vary in speed.  Those in Windows NT tend to be significantly
  68. slower than those in Windows 95.  Even in Windows 95, some drivers or
  69. hardware might be slower than Kermit 95 was designed for.  Kermit 95's
  70. default screen-updating cycle is 100 milliseconds (1/10 second); if your
  71. video driver is slower than that, you might be able to make Kermit go faster
  72. by increasing (yes, increasing) its screen-update interval, for example:
  73.  
  74.   SET TERMINAL SCREEN-UPDATE FAST 200
  75.  
  76. Flickering can occur when the video driver is not performing a comparison
  77. between what is already on the screen and what it is being asked to write.
  78. So it paints the entire window (which takes time) even when it doesn't have
  79. to.  When acceleration is on (and supported by the driver) minimal screen
  80. paints occur and screen updates should be fast.  In the Control Panel either
  81. on the Display object or the System Object, there is a performance page which
  82. allows you to set the Video Acceleration properties.  Make sure this is set
  83. to use full acceleration.  The only flickering you should see in this case is
  84. the mouse pointer, since it is turned off and on, before and after each
  85. console screen paint.
  86.  
  87. If that doesn't help, you can experiment with Kermit 95's SET TERMINAL
  88. SCREEN-UPDATE FAST and SMOOTH options to choose which algorithm is used to
  89. update the screen when new data arrives from the host.  Whenever a byte
  90. arrives from the host it is processed by an incoming data thread.  If it
  91. results in a screen write, an internal screen buffer is updated and a "dirty"
  92. flag is set.  When using the FAST algorithm, the screen buffer is copied to
  93. the physical screen on a timer thereby allowing the maximum data throughput
  94. from the host to occur regardless of the speed of the video drivers.  This is
  95. the default.  The negative aspect of this method is that on really fast
  96. connections it is possible for some screen writes to never make it to the
  97. screen, e.g. during continuous scrolling (but the data is processed correctly,
  98. and can be viewed in the scrollback buffer).  The SMOOTH option says to copy
  99. the screen buffer to the window whenever the dirty flag is set.  This results
  100. in much slower data handling, and a potentially significant increase in the
  101. number of screen writes.
  102.  
  103. - Frank